1. Field of the Invention
The present invention relates generally to an improved data processing system and in particular to a method and apparatus for maintaining stateful data in a network environment. Still more particularly, the present invention relates to a computer implemented method, apparatus, and computer usable program code for managing data in a partitioned application server environment.
2. Description of the Related Art
Modern business computer network systems handle vast quantities of information and vast numbers of complex transactions on an hourly basis. To handle the workload imposed by the amount of information and the number of complex transactions, computer network systems are composed of multiple physical servers executing one or more pieces of software designed to process the transactions. These pieces of software are known as applications.
An instance of an application on a physical server is known as an application server, also known as appserver. One or more application servers can be grouped together into a cluster in order to increase the processing power of an application.
Another problem associated with managing large quantities of complex transactions is downtime caused by failure of a single appserver failure. In order to minimize downtime, systems are configured to achieve nearly instantaneous failover. Achieving instantaneous failover involves making all critical data easily available even after failure of an application server. Making critical data easily available involves saving the critical data in a manner such that a backup application server can access the critical data in case of a failure of the primary server.
For example, critical data can be made easily available by saving the critical data in a shared storage medium. An example of a shared storage medium is a database. In this example, each time an application server processes a request and generates data which should be available for future requests, the application server copies the data to the shared medium. Thus, every application server has access to critical data from every other application server. Accordingly, in the event of a failure of one application server, the request is routed to another application server that can retrieve the critical data from the shared medium and process the request.
Another approach to making critical data easily available is to use replication groups. A replication group is a number of application servers associated with each other for storage purposes. For example, a cluster of application servers can be divided into one or more replication groups. Within a replication group, critical data is distributed to all other members of the replication group and kept up to date. In essence, any time a member of the replication group updates its critical data, that member communicates those updates to one, a number, or all other application servers in the replication group. Thus, one or more other members of the replication group will be up to date and can act in the absence of the first member of the replication group. In the event of a failure of one of the application servers, the other members of the replication group can handle requests for the failed server.
Different types of critical data exist. One type of critical data is stateful data. Stateful data is any data pertaining to a client that persists for a series of requests known as a session. A session is a series of requests that begins with the creation of a first stateful data and ends with a specific request from the client to end the session. A session may also be ended via a limit condition, such as a time limit that prevents a session from lasting more than a predetermined time. The contents of stateful data vary because the application directly determines the stateful data.
Once a session is created, a client is said to have affinity to the sever in which the stateful data was created. Affinity is when a client is assigned to a particular application server, possibly along with a list of backup servers from the same replication group. Affinity between a client and an application server is established because the particular application server processed a previous request that generated stateful data in the current session. Thus, when affinity is established, all future requests are routed to that same application server that first created the stateful data, unless that same application server fails and one of the backups takes over.
As described above, a session begins when a client makes a first request that generates stateful data and ends when a client terminates the session through a specific request, such as a logout request, to the application. The session may also be terminated when the session times out due to the client's non-responsiveness. A client can make a series of stateless requests that do not include generation of or reference to stateful data before, during or after the session. These stateless requests made before and after the session are not part of the session, but stateless requests during the session are included in the session for proper management of the stateful data.
When affinity exists between a client and an application server, requests from the client and responses from the application server contain affinity information. Affinity information includes the identity of the primary affinity application server, the backup application server available in case of failure of the affinity server, and a key that uniquely identifies the client's stateful data in the affinity application server's stateful data repository and in all backup application servers' stateful data repositories. A stateful data repository can be any physical object or data structure suitable for storing data, such as a hard disk drive, random access memory, and other forms of physical memory, or a database, a flat data file, or other forms of data structures suitable for holding data.
To better manage large amounts of complex data, applications can be split into one or more logical partitions known as application partitions. An application partition is designated to handle a subset of all requests for an application. A set of rules in the application maps each request into a particular application partition and each application partition onto an application server. An application partition typically resides only on one application server, but can also reside on a group of application servers. By partitioning the application in this manner, many optimizations can be made via reducing the dataset that can occur on any one application server at any one time.
An example of the above-described concepts in use can be described for a large clothing retailer that maintains a complex business system. A client orders a pair of pants and a shirt online. The client first make requests to purchase a shirt by adding the shirt to his shopping cart. The client then makes a series of requests to purchase a pair of pants and add the pair of pants to the shopping cart. To more efficiently execute these requests, the business system is designed to route requests associated with the purchase of the pair of pants to one application server partition and the requests associated with the purchase of the shirt to a second application server partition. These two application server partitions can reside on separate physical servers. The first and second application server partitions do not necessarily communicate with each other to coordinate the sale to the single client.
The failure to communicate results from the fact that stateful data related to the client is not exchanged between the first and second application partitions. In the above example, data related to the client and the transaction is stateful data. Specifically, data related to the contents of the shopping cart, and data related to the fact that the shirt and the pair of pants are to be shipped to the same client in the same package, are stateful data.
Current solutions to address this problem of maintaining stateful data in a partitioned environment involve creating a façade layer to the application server environment. The façade layer is the entry point to the application server environment and maintains a master copy of the stateful data. The facade layer is placed logically in front of a set of application server partitions. When the façade layer receives a request, the façade layer makes a remote request to the appropriate application server partition including any stateful data needed by the application server partition to process the request. Thus, the client or customer communicates with the façade layer, which then decides to which application server partition a request should be routed. Eventually, the appropriate application server partition sends a response back to the façade layer. The façade layer reads and processes the response, which can include updates to stateful data, before sending out a final response to the client or customer.
Continuing the above example, the two requests for adding the pair of pants and shirt to the shopping cart are coordinated by the façade layer. The request for the pair of pants is received by the facade layer and then forwarded to the appropriate application server partition to obtain price information and other information regarding the shirt and the purchase of the shirt. The facade layer receives a response from the application server partition, processes the response and then finds that a pair of pants was added to the shopping cart at a certain price. The application server then updates the stateful data so that this fact persists across any subsequent requests. On the subsequent request for a shirt, a similar pattern occurs and ultimately the facade layer updates the stateful data to show both a pair of pants and a shirt in the shopping cart. Finally, the user sends a request to purchase the contents of the shopping cart. The facade layer will route the request to purchase to a particular application server or application server partition designated to handle purchase requests. The purchasing application server or application server partition processes the order, causes the transfer of funds, and causes the shirt and the pair of pants to be shipped to the client in one package.
A problem with the façade layer solution is that the façade layer is extremely complex in an environment that is already complex. Thus, the façade layer solution is difficult and expensive to maintain. Additionally, the facade layer also consumes more server side resources, including processor cycles and network bandwidth, ultimately reducing any benefit gained from implementing application server partitions in the first place.